A2E · Operating Manual
How the platform runs a project — verbatim to the process
This is the recipe. It follows PMBOK® Guide (8th Ed.) process groups and the repo's gate model exactly. Every step names its standard. Where logic is a constructed engineering choice rather than a standard, it says so.
⚠ Grounding rule — no drift
EVM (EIA-748) and CPM formulas are standard and verbatim. Closeout gates and the flowdown engine come from A2E_ContractOps. Scope-adjudicator thresholds and sample data are constructed and labeled. Clause snapshots are not legal ground truth — the eCFR (Title 48) is. Verify before any compliance action.
Is the clause list complete?
No. 40 curated high-frequency flowdown clauses. The full FAR Part 52 + DFARS 252 set is thousands of clauses, amended continuously. The complete, current, authoritative source is the eCFR (Title 48) / 1102tools ecfr-mcp. The tool links out to it rather than posing as the system of record.
DCAA vs. DCMA — how they attach
DCAA (Defense Contract Audit Agency) audits cost — incurred-cost submissions, indirect rates, accounting-system adequacy, proposal audits → drives the Audit-Prep templates. DCMA (Defense Contract Management Agency) administers performance — surveillance, EVM system validation (the DCMA 14-point schedule check in the Schedule module), GFP/property, quality, delegated ACO functions.
02
Who does what (7 roles)
{{ r.name }}
{{ r.does }}
03
Startup sequence — first, next, next…
The exact order. Each step names its PMBOK process group and the module you work in. Gates block until artifacts exist.
{{ st.title }}
{{ st.group }}
→ {{ st.module }}
{{ st.detail }}
Gate: {{ st.gate }}
04
Definition of Ready — when may work begin?
Execution does not start until every item below exists. This is the app's opinionated gate — the differentiator you asked for: no working from a half-baked plan.
✓
{{ ri.item }}
{{ ri.src }}
05
Data intake — what reads it and builds the tracker
The pipeline from raw input to a live task tracker. Honest split between what this prototype does and what attaches at deployment.
{{ p.stage }} {{ p.who }}
{{ p.detail }}
What reads it?
Prototype: the PM enters WBS items, tasks, and resources; the engine (renderVals) derives everything downstream — Earned Value, CPI/SPI, EAC, critical path via forward/backward pass, sprint velocity, and flowdown determinations via the ported applicability.evaluate(). Nothing is faked; every number is computed. Deployment: document ingestion (SOW → WBS extraction) and live federal data (SAM.gov, eCFR, USAspending) attach through the 1102tools MCP servers + a backend. The JSON data model exports for that handoff.
06
Where issues are tracked
The RAID Log is the in-app system of record. Its lifecycle, and how it maps to Jira / Azure DevOps at deployment:
In-app (RAID Log)
Risks scored P×I (5×5), Actions with owner + due date, Issues with escalation path, Decisions with rationale. The Scope Adjudicator auto-creates a RAID entry on every verdict. Change Control auto-creates a CR on a Scope-Creep verdict.
At deployment (external tracker)
Each schedule task and RAID/CR item carries an ID field that maps to a Jira or Azure DevOps work item, so the schedule links to a real issue tracker. Standard stack: Jira/ADO (issues), MS Project/Primavera P6 (schedule), ServiceNow or Power Automate + SharePoint (CR approval flow).
07
Change control — who can submit, who approves
The scope-creep defense. A task never silently enters the baseline — it is adjudicated, then gated.
Every module tied to the standard it implements — the PMP-exam backbone.
Standard
Module
Grounding
{{ cw.std }}
{{ cw.mod }}
{{ cw.tag }}